This invention relates to the field of computer systems. More particularly, a system and methods are provided for dynamically adjusting parameters of a communication interface, in response to a dynamic measurement of the interface workload, to modify the manner in which the communication interface coalesces interrupts associated with the forwarding of communications to a host processor.
When a communication interface (e.g., a network interface circuit, or NIC) receives a packet, frame or other communication from a communication link, it is usually configured to notify a host processor via an interrupt. In early network interfaces, a separate interrupt may have been issued for each packet the interface received from the network and forwarded to the host. As long as data rates were low, packets would arrive relatively infrequently, and a host processor would not be overwhelmed.
However, at today's data rates of 1 gigabit per second and higher, if a separate interrupt were issued by a network interface for every packet it received and passed to a host processor, it would signal more than 80,000 interrupts per second. Even a modem, high-performance, processor, if besieged with so many interrupts, would likely be incapable of processing them and switching in and out of an interrupt-processing mode, while still handling normal processing tasks.
One method of decreasing the number of interrupts issued by a communication interface to a host processor is called interrupt blanking or interrupt coalescing. With interrupt blanking, a communication interface may accumulate multiple packets before issuing an interrupt to a host processor. Illustratively, when the communication interface receives a first packet, it initiates a packet counter and a latency timer. When either a predetermined number of packets is accumulated or a predetermined period of time elapses, all of the accumulated packets are sent to the host and one interrupt is signaled.
Interrupt blanking or coalescing has typically been implemented solely within the communication interface hardware. The parameters that determine when an interrupt may be issued (i.e., maximum packet count, maximum latency) were static parameters programmed into the communication interface before or during its initialization. The parameters cannot be changed without resetting the interface and disrupting the communication flow through the interface.
Thus, the parameters for controlling interrupt blanking must be configured before the pattern of traffic to be handled is known. At one extreme, the traffic may be relatively heavy; at the other, the traffic may be relatively light. A heavy traffic pattern is typical of the transfer of a large amount of data, and involves the receipt of many separate packets relatively close in time. A light traffic pattern, involving the receipt of relatively few packets, spread out over time, may be indicative of a request-response communication flow between a client and a server, or other entities.
If a communication interface was optimized for one type of traffic, it would necessarily handle the other type inefficiently. Thus, configuring the interrupt blanking parameters for a high packet count and high latency would allow for efficient handling of a large amount of data, but would provide poor performance for a request-response flow. A low packet count and low latency would entail the opposite. Thus, the parameters have typically been optimized for either heavy or light traffic, thereby handling the other type very ineffectively, or have been set to median values, in which case both types are handled equally inefficiently.
Because interrupt blanking parameters have been static, as the traffic received by a communication interface varied from what it was optimized for, performance would vary commensurately. The parameters could not be dynamically configured to meet the changing traffic pattern.